ByeBoo-iOS/ByeBoo-iOS/Domain/UseCase/CheckForceUpdateUseCase.swift (1)

14-14: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

타입명 표기 불일치: Usecase → UseCase.

DefaultCheckForceUpdateUsecase만 소문자 case로 되어 있어, 코드베이스 전반의 Default*UseCase 명명 규칙과 어긋납니다.

♻️ 제안 수정

-struct DefaultCheckForceUpdateUsecase: CheckForceUpdateUseCase {
+struct DefaultCheckForceUpdateUseCase: CheckForceUpdateUseCase {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ByeBoo-iOS/ByeBoo-iOS/Domain/UseCase/CheckForceUpdateUseCase.swift` at line
14, The type name in DefaultCheckForceUpdateUsecase is inconsistent with the
project’s Default*UseCase naming convention. Rename the struct to
DefaultCheckForceUpdateUseCase and update any matching references so the
CheckForceUpdateUseCase implementation follows the same capitalization pattern
as the rest of the codebase.

ByeBoo-iOS/ByeBoo-iOS/Data/Persistence/Service/ForceUpdateManager.swift (3)

17-21: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

프로덕션에서 minimumFetchInterval = 0은 스로틀링 위험이 있습니다.

디버그/개발용이 아닌 앱 시작 시마다(매 실행) 무조건 fetch interval을 0으로 설정하고 있습니다. Firebase 공식 문서에서는 이 설정을 개발 전용으로 명시하며, 트래픽이 많은 앱에서는 시간당 서버 측 쿼터에 걸려 스로틀링될 수 있다고 경고합니다. 스로틀링이 발생하면 fetch()가 실패하고 checkForUpdate()는 항상 false를 반환하게 되어, 강제 업데이트가 필요한 사용자도 감지하지 못할 수 있습니다.

DEBUG 빌드에서만 0으로 설정하고, 프로덕션에서는 합리적인 간격(예: 몇 시간 단위)을 사용하는 것을 권장합니다.

♻️ 제안 수정

     init() {
         let settings = RemoteConfigSettings()
-        settings.minimumFetchInterval = 0
+        `#if` DEBUG
+        settings.minimumFetchInterval = 0
+        `#else`
+        settings.minimumFetchInterval = 3600
+        `#endif`
         RemoteConfig.remoteConfig().configSettings = settings
     }

Firebase 문서 확인 결과: "During development, it's recommended to set a relatively low minimum fetch interval... Keep in mind that this setting should be used for development only, not for an app running in production."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ByeBoo-iOS/ByeBoo-iOS/Data/Persistence/Service/ForceUpdateManager.swift`
around lines 17 - 21, ForceUpdateManager.init() is setting
RemoteConfigSettings.minimumFetchInterval to 0 unconditionally, which should be
limited to development use only. Update the initialization logic in
ForceUpdateManager so that RemoteConfig.remoteConfig().configSettings uses a
zero interval only for DEBUG builds, and uses a reasonable production interval
otherwise; keep the change localized to the init() setup and preserve the
existing RemoteConfig configuration flow.

---

1-6: 📐 Maintainability & Code Quality | 🔵 Trivial

파일 헤더 주석이 실제 파일명과 다릅니다.

주석에는 RemoteConfigeManager.swift로 되어 있지만 실제 파일명은 ForceUpdateManager.swift입니다.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ByeBoo-iOS/ByeBoo-iOS/Data/Persistence/Service/ForceUpdateManager.swift`
around lines 1 - 6, The file header comment is using the wrong filename, so
update the top-of-file header in ForceUpdateManager.swift to match the actual
file name instead of RemoteConfigeManager.swift. Keep the rest of the header
unchanged and ensure any generated template or metadata in this file reflects
ForceUpdateManager.

---

23-34: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

throws 선언이 무의미하고, 오류가 조용히 삼켜집니다.

checkForUpdate()는 내부에서 모든 에러를 catch해 항상 false를 반환하므로 실제로는 절대 throw하지 않습니다. 그런데도 프로토콜과 함수 시그니처는 throws를 유지하고 있어, 호출부(CheckForceUpdateUseCase.execute(), SplashViewModel.checkForceUpdate())에서 불필요한 try/do-catch가 이중으로 존재하게 됩니다. 또한 fetch/activate 실패 시 에러 로그가 전혀 남지 않아 실패 원인 파악이 어렵습니다.

throws를 제거해 계약을 명확히 하거나, 최소한 catch 블록에서 에러를 로깅하는 것을 제안합니다.

♻️ 제안 수정 (에러 로깅 추가)

     func checkForUpdate() async throws -> Bool {
         do {
             try await remoteConfig.fetch()
             try await remoteConfig.activate()
 
             let minimumVersion = remoteConfig["min_version_code"].stringValue
             
             return isUpdateRequired(minimumVersion: minimumVersion)
         } catch {
+            ByeBooLogger.debug("강제 업데이트 확인 실패: \(error)")
             return false
         }
     }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ByeBoo-iOS/ByeBoo-iOS/Data/Persistence/Service/ForceUpdateManager.swift`
around lines 23 - 34, `ForceUpdateManager.checkForUpdate()` currently swallows
every error and always returns false, so the `throws` on the method and its
protocol contract are misleading. Either remove `throws` from `checkForUpdate()`
and the related call sites that reference it, or keep the non-throwing behavior
but add error logging inside the `catch` so fetch/activate failures are visible.
Update the usages in `CheckForceUpdateUseCase.execute()` and
`SplashViewModel.checkForceUpdate()` accordingly so they no longer wrap this
call in unnecessary try/do-catch logic.

ByeBoo-iOS/ByeBoo-iOS/Domain/DomainDependencyAssembler.swift (1)

258-261: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

다른 리포지토리와 달리 DefaultForceUpdateManager()가 DIContainer를 거치지 않고 직접 인스턴스화됩니다.

같은 파일의 다른 모든 등록은 파일 상단 guard let ... = DIContainer.shared.resolve(type: ...Interface.self)로 먼저 리포지토리를 해석한 뒤 UseCase 생성 시 주입하는 패턴을 따릅니다. 반면 CheckForceUpdateUseCase 등록에서는 DefaultForceUpdateManager()를 인라인으로 직접 생성해 주입합니다. 이는 기존 DI 컨벤션과 다르며, 테스트 시 목(mock) 구현체로 교체하기 어렵게 만듭니다.

ForceUpdateManager도 DIContainer에 등록한 뒤 resolve하여 사용하는 방식으로 통일하는 것을 제안합니다.

♻️ 제안 수정

+        DIContainer.shared.register(type: ForceUpdateManager.self) { _ in
+            return DefaultForceUpdateManager()
+        }
+        
+        guard let forceUpdateManager = DIContainer.shared.resolve(type: ForceUpdateManager.self) else {
+            ByeBooLogger.error(ByeBooError.DIFailedError)
+            return
+        }
+        
         DIContainer.shared.register(type: CheckForceUpdateUseCase.self) { _ in
-            return DefaultCheckForceUpdateUsecase(repository: DefaultForceUpdateManager())
+            return DefaultCheckForceUpdateUseCase(repository: forceUpdateManager)
         }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ByeBoo-iOS/ByeBoo-iOS/Domain/DomainDependencyAssembler.swift` around lines
258 - 261, The CheckForceUpdateUseCase registration is bypassing the existing DI
pattern by creating DefaultForceUpdateManager() directly instead of resolving it
through DIContainer.shared. Update the DomainDependencyAssembler registration so
ForceUpdateManager is registered and then injected via resolve, matching the
other use case bindings in this file and keeping the dependency swappable for
tests. Use the CheckForceUpdateUseCase and DefaultForceUpdateManager symbols to
locate the affected registration and align it with the surrounding repository
injection style.

ByeBoo-iOS/ByeBoo-iOS/Presentation/Feature/Login/ViewModel/SplashViewModel.swift (1)

60-74: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

catch 블록에서 에러 로깅 누락

autoLogin()은 실패 시 ByeBooLogger.error(error)로 에러를 남기는 반면, checkForceUpdate()의 catch는 에러를 그대로 버리고 false만 전송합니다. Remote Config fetch 실패가 강제 업데이트라는 핵심 안전장치의 동작을 좌우하는 만큼, 실패 원인을 남겨두는 것이 운영/디버깅에 유리합니다.

🪵 제안 수정

             } catch {
+                ByeBooLogger.error(error)
                 forceUpdateSubject.send(false)
             }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@ByeBoo-iOS/ByeBoo-iOS/Presentation/Feature/Login/ViewModel/SplashViewModel.swift`
around lines 60 - 74, `SplashViewModel.checkForceUpdate()`의 `catch` 블록에서 에러가
버려지고 있어 실패 원인을 추적할 수 없습니다. `autoLogin()`처럼 `ByeBooLogger.error(error)`를 추가해
Remote Config fetch 실패를 로그로 남기고, 그 뒤 기존처럼 `forceUpdateSubject.send(false)`를
유지하도록 수정하세요. `checkForceUpdateUseCase.execute()`를 감싸는 `Task` 내부의 예외 처리 흐름을 찾아
반영하면 됩니다.

ByeBoo-iOS/ByeBoo-iOS/Presentation/Common/Modal/ForceUpdateModalView.swift (1)

18-19: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

타이틀/설명 라벨에 줄바꿈·가로 제약 추가 권장

titleLabel, descriptionLabel은 centerX 제약만 있고 numberOfLines나 leading/trailing 제약이 없습니다. 기본값(numberOfLines = 1)이라 큰 접근성 폰트 크기나 더 긴 문구로 바뀔 경우 텍스트가 잘리거나 모달 경계를 벗어날 수 있습니다.

✏️ 제안 수정

     private let titleLabel = UILabel()
     private let descriptionLabel = UILabel()

     override func setStyle() {
         backgroundColor = .grayscale900
         layer.cornerRadius = 12
         
+        titleLabel.numberOfLines = 0
+        descriptionLabel.numberOfLines = 0
+
         titleLabel.applyByeBooFont(

         titleLabel.snp.makeConstraints {
             $0.top.equalToSuperview().inset(24.adjustedH)
-            $0.centerX.equalToSuperview()
+            $0.horizontalEdges.equalToSuperview().inset(24.adjustedW)
+            $0.centerX.equalToSuperview()
         }
         descriptionLabel.snp.makeConstraints {
             $0.top.equalTo(titleLabel.snp.bottom).offset(16.adjustedH)
-            $0.centerX.equalToSuperview()
+            $0.horizontalEdges.equalToSuperview().inset(24.adjustedW)
+            $0.centerX.equalToSuperview()
         }

Also applies to: 29-39, 43-50

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ByeBoo-iOS/ByeBoo-iOS/Presentation/Common/Modal/ForceUpdateModalView.swift`
around lines 18 - 19, `ForceUpdateModalView`의 `titleLabel`과 `descriptionLabel`은
현재 가로 제약이 부족하고 기본 단일 줄 설정이라 긴 문구나 큰 접근성 폰트에서 잘릴 수 있습니다. `setupUI`/레이블 설정 로직에서 두
라벨의 `numberOfLines`를 여러 줄로 허용하고, `centerX`만 쓰는 대신 leading/trailing 제약을 추가해 모달 폭
안에서 줄바꿈되도록 수정하세요. `titleLabel`과 `descriptionLabel`을 참조하는 레이아웃 구성 전체를 함께 점검해 안전한
여백을 유지하세요.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

ByeBoo-iOS/ByeBoo-iOS/Data/Persistence/Service/ForceUpdateManager.swift (1)

36-39: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

세그먼트 수가 다른 버전 문자열은 직접 비교하지 마세요
String.compare(_:options: .numeric)는 숫자 구간만 자연 정렬할 뿐, 1.3와 1.3.0처럼 세그먼트 개수가 다른 버전을 같은 값으로 보지 않습니다. CFBundleShortVersionString과 min_version_code 형식이 조금만 달라져도 불필요한 업데이트가 트리거될 수 있으니, 세그먼트를 정수로 파싱해 길이를 맞춘 뒤 비교하는 쪽이 안전합니다.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ByeBoo-iOS/ByeBoo-iOS/Data/Persistence/Service/ForceUpdateManager.swift`
around lines 36 - 39, The version check in isUpdateRequired(minimumVersion:) is
relying on String.compare(_:options: .numeric), which can mis-handle version
strings with different segment counts like 1.3 and 1.3.0. Update the comparison
logic in ForceUpdateManager to parse currentAppVersion and minimumVersion into
numeric version segments, normalize missing segments by padding as needed, and
compare the resulting components directly instead of using string comparison.
Keep the existing logging in isUpdateRequired(minimumVersion:) but ensure the
decision is based on the parsed version arrays.